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3375 and 3380 Device Construction 


IBM 3375s and 3380s have multiple logical devices corresponding to 
unique device addresses on each physical unit. Both have two logical 
volumes per physical spindle. The 3375s can be given an_ second 
controller by acquiring a model D1. The 3380s can also have a second 
controller by acquiring a model AAH4, With these second controllers, 
two data transfers on the’ string can occur simultaneously. However , 
if one logical volume on a physical spindle is busy, any attempt to 
access the other volume on the same spindle will also report back a 
busy. This is a subtle design feature (deficiency). with the 3375s. 
Although I would be happy for someone to correct me, I believe that 
the same feature is present with the 3380s. Cornell has addressed the 
problem , excuse the pun, by putting high-use data (like the CP 
nucleus, spool, and paging spaces,) on even numbered addresses. We 
reserve the odd numbered addresses for relatively low-use user data. 
After we gain some experience with the approach, I hope we will be 
able to report how well it performs. 


Summar y 


The following chart trys to encapsulate the major concerns about an 
I/O configuration when you are using VM/370 in a complex environment. 
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Things to Remember 


1. RCTLUNIT - Feature= 32-Device 


2. RDEVBLOK Counters —- 1 per real address. 
Real I/0 path usage impossible to determine. 


oe ee ee ee ee ee ee 


Sharing -- Reserve/Release -- Real & Virtual. 


4, 3375s & 3380s with two addresses per spindle 
and two heads of string 


WW 
e 


5. In multi-CPU environments, watch SMART's 
CU/Device Busy statistics for contention 
between real systems. 

6. IOCP Restrictions with ALTCU. 


7. Channel Rotate Modification from VMSHARE. 
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IUCV OVERVIEW 


The Inter-User-Communications-Vehicle (IUCV) was introduced in VM/SP Release 1. 
It is a general use communications medium which allows communications between 
two virtual machines and/or CP. It allows two programs running in two different 
virtual machines to communicate by sending messages back and forth internally in 
the same fashion that two people would communicate via the CP message command. 
Currently, IUCV supports three system services, which will be covered in detail 
later: 


1. Console Communications 
2. Message 
3. DASD Block I/0 


When two virtual machines are using IUCV to communicate, it appears to them as 
though they actually have a real communications link between the two virtual 
machines. In actuality, both virtual machines have a link with the IUCV code in 
CP. CP keeps track of which link from virtual machine 1 corresponds to the link 
from virtual machine 2. Because this is all transparent to the user, IUCV can be 
a well defined asynchronous communications medium. 


IUCV CONCEPTS 


IUCV is implemented as an operation code of X'B2FO'. It is a software only 
implementation, meaning that when the hardware tries to execute the X'B2F0' 
instruction, a program check is generated, the CP program check handler receives 


'control, recognizes that it is an IUCV instruction, and gives control to the CP 


IUCV code. There are 18 functions available which allow two communicators to 
establish communications, perform communications, and terminate communications, 
as well as some miscellaneous additional functions. IUCV supports multiple con- 
current communications, and also multiple parallel concurrent communications. 
There are some directory controls available, so installations can control who is 
authorized to use it. An IUCV communication is really an asynchronous communi- 
cation with CP. Virtual machines are notified that an IUCV event has occurred 
via an IUCV external interrupt. This gives IUCV its asynchronous nature. An 
assembler macro is provided to aid the user in coding the IUCV parameter list. 


IUCV Messages 


IUCV Information transfer is via a "message". To IUCV itself, the message is 
actually a control block which contains information about the source and target 
of the message and may or may not actually contain the message data itself. An 
IUCV message may be one or two way and may be a normal or a priority message. An 


IUCV message is created via the IUCV SEND function, and internally, the IUCV 


message is moved among IUCV queues. 
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IUCV Queues 


There are 3 IUCV queues for each virtual machine. A send queue, which is where 
incoming message blocks are placed, a receive queue where message blocks are 
placed while a reply is pending, and a reply queue where message blocks are 
placed once. the message has been replied to. The life of an IUCV message block 
is as follows. An IUCV SEND creates the message and the message block is placed 
on the target's send queue. The target of the message issues the IUCV RECEIVE 
function and the message block is moved to the target's receive queue. The tar- 
get then issues the REPLY function, and the message block gets moved to the 
source's reply queue. Once the "incoming reply" external interrupt is reflected 
to the virtual machine, the message block ceases to exist. The [UCV queues are 
First-In-First-Out (FIFO) with priority. 


IUCV Paths 


A "path" is a communications capability between two IUCV communicators. It is 
the pipeline for communications, as messages move across a path. Multiple paths 
to different virtual machines are allowed, and multiple paths to one virtual 
machine are permitted also. A path is numbered and well defined at both ends. 
Each end of an IUCV path is assigned a number by IUCV when the path is estab- 
lished with an IUCV CONNECT or ACCEPT. Path numbers are assigned sequentially 
starting from zero. Since each path is well defined at both ends, either end of 
the path can SEVER or QUIESCE it. 


IUCV External Interrupts 


External interrupts are used to communicate asynchronously with virtual 
machines. Whenever an IUCV event has occurred for a virtual machine, CP 
reflects an IUCV external interrupt. The IUCV external interrupt type is 
X'4000', which is unique. When an external interrupt is reflected to a virtual 
machine, information about the IUCV event which has just occurred is stored in a 
buffer which is identified to IUCV by the virtual machine via the Declare Buffer 
function. There are some controls which allow a virtual machine to disable IUCV 
external interrupts: 


* Bit 7 in the PSW can be turned off to disable all external interrupts. 


bd Bit 30 in control register 0 can be turned off to disable IUCV external 
interrupts. 


¢ The IUCV SETMASK and SETCMASK functions can be used to disable specific IUCV 
external interrupt types. 


IUCV external interrupts fall into two categories. Path related interrupts 
include connection pending, connection complete, path quiesced, path resumed, 
and path severed. Message related interrupts are incoming priority and 
non-priority messages and incoming priority and non-priority replies. - Each 
individual IUCV external interrupt type can be masked off via the IUCV SETMASK 
and SETCMASK functions. 
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IUCV FUNCTIONS 


IUCV functions fall into four categories: 
° Establishing communications 

° Message handling 

° Some miscellaneous functions 

: Terminating communications 


The first catagory, establishing communications, contains four functions: Que- 
ry, Declare Buffer, Connect, and Accept. The Query function returns the maximum 


‘number of paths which are allowed in a virtual machine and the size of the 


external interrupt buffer needed. The Declare Buffer function identifies the 
area of storage which the virtual machine wants IUCV to use as its external 
interrupt buffer. The Connect function initiates a communication with another 
virtual machine, CP or itself. The Accept function, completes a communications 
link initiated by another communicator. 


The message handling category contains five IUCV functions: Send, Describe, 
Receive, Reply, and Test Completion. The Send function begins a communication 
and creates a message block in IUCV. The Describe function is used to interro- 
gate IUCV to see if any pending messages are waiting. This function is used to 
avoid having CP reflect an incoming message external interrupt or is used in CP 
code where external interrupts cannot be generated. The Receive function is 
used to obtain the message data after an incoming message external interrupt has 
occurred. The Reply function is used to respond to a two-way message. The Test 
Completion function is used to interrogate [UCV to see if there are any incoming 
replies and avoid the external interrupt. 


The third category consists of seven miscellaneous functions: Reject, Purge, 
Quiesce, Resume, Set Mask, Set Control Mask, and Test Message. Reject simply 
rejects an incoming message and tells the sender you do not wish to receive it. 
Purge is used by the initiator of a message to remove it from IUCV. Quiesce dis- 
allows any incoming messages on a path and Resume returns the path to normal. 
Set Mask is used to prevent specific message related and all control IUCV 
external interrupts from occurring. Set Control Mask prevents individual con- 
trol external interrupts from occurring. Test Message will place the issuer's 
virtual machine in a wait state if no incoming messages or replies are pending. 


The final category, terminating communications has two functions: Sever and 
Retrieve Buffer. The Sever function is used to terminate a path and the 
Retrieve Buffer function is used to terminate the IUCV environment for the vir- 
tual machine. No IUCV functions are permitted after the Retrieve Buffer func- 
tion has been issued. 


TYPES OF IUCV MESSAGES 


An IUCV message can be either a two-way or a one-way message. For a two-way mes- 
sage, the IUCV Send function creates the message and the message is placed on 
the target's send queue. The Target side receives an incoming message external 
interrupt and issues the Receive function to transfer the message data from the 
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source's virtual machine to the target's. Internally, IUCV then moves the mes- 
sage block to the Target's receive queue. The target then issues the Reply 
function to respond to the message, IUCV transfers the reply data to the 
source's virtual machine and moves the message block to the source's reply 
queue. Once the incoming reply external interrupt is reflected, the communi- 
cation is complete. 


For a one-way message, the IUCV Send function creates the message and the mes- 
sage is placed on the target's send queue. The target side receives an incoming 
message external interrupt and issues the Receive function to transfer the mes- 
sage data from the source's virtual machine to the target's. Since no reply is 
needed, IUCV moves the message block to the source's reply (or message complete) 
queue. Once the incoming reply (message complete) external interrupt is 
reflected, the communication is complete. 


Parameter List Data Protocol 


In VM/SP Release 3, a new "parameter list data" protocol has been established. 
With this protocol, message data is passed in the IUCV parameter list itself 
instead of in a remote buffer. This protocol is defined to IUCV via the 
PRMDATA=YES option on the IUCV Connect or Accept. A message using this protocol 
is identified via the DATA=PRMMSG and PRMMSG= options on an IUCV Send or Reply. 
The message data itself may be up to 8 bytes in length. Using this new protocol 
will cause a reduction in IUCV path length as IUCV will no longer have to move a 
potential large amount of data from one virtual machine to another. Also with 
this new protocol, the target of the message no longer has to issue an IUCV 
Receive function, since the message data is available in the external interrupt 
buffer when the interrupt is reflected. 


TERMINATING COMMUNICATIONS 


When a communicator wishes to terminate an communications path, he issues an 
IUCV Sever function on the path number which was given to him by IUCV when the 
path was established. All active messages are either purged or rejected, and 
when control returns from IUCV, the path is no longer there. On the other side 
of the path in the other virtual machine, a sever external interrupt is 
reflected. The program in that virtual machine must then issue an IUCV Sever 
for the corresponding path number that identifies the path in that virtual 
machine. Once IUCV returns control, the path is no longer there on his side 
either. 


QUIESCING A PATH 


When the IUCV Quiesce function is issued on a path, no incoming messages are 
permitted. All out going messages are still allowed. Each end of the IUCV path 
is independent, so one end can be in Quiesce mode while the other is not. This 
function can be used for clean-up or catch-up work. A service virtual machine 
can suspend any incoming requests by Quiescing a path until it is caught up, or 
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it is ready to receive more requests. Normal communication is re-established 
with the IUCV Resume function. 


DIRECTORY CONTROLS 


There are some directory controls which allow an installation to control how 
IUCV will be used in its environment and who is authorized to use it. The IUCV 
statement can be specified in a user's directory entry to control which other 
users can connect to him. On this statement an installation can identify wheth- 
er priority messages will be allowed and also how many messages can be outstand- 
ing on a path at any particular time. The default message limit is 10 and the 
maximum is 255. 


Instead of a userid, two special keywords can be specified: ALLOW and ANY. 
ALLOW indicates that any userid can connect to this virtual machine. This key- 
word can be used for service virtual machines that everyone on the system might 
want to connect to. The ANY keyword indicates that this userid can connect to 
any virtual machine whether that virtual machine has an entry for it in its 
directory or not. This is useful for system programmer userids so they can con- 
nect to anyone. 


The MAXCONN keyword on the option statement can be used to define. the maximum 


number of paths allowed in this virtual machine. The default is 4 and the maxi- 
mum is 65,535. 
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SYSTEM SERVICES 


There are 3 system services currently supported in IUCV. 
. Console Communications | 
* Message 


e DASD Block I/O 


CONSOLE COMMUNICATIONS 


To connect to the Console Communications system service, *CCS should be speci- 
fied as the userid in the IUCV connect parameter list. This system service is a 
specialized interface for passing screen data. The information passed is simi- 
lar to the information returned from Diagnose 58. This system service was 
introduced in VM/SP Release 1 and is used by the VCNA service virtual machine. 


MESSAGE 


To connect to the Message system service, *MSG should be specified as the userid 
in the IUCV connect parameter list. This system service is used to intercept 
console output. Instead of having console output displayed on the screen, the 
output can be sent to the virtual machine via IUCV. The type of output sent or 
displayed, can be controlled via the CP SET command. This system service was 
introduced in VM/SP Release 2 and is used by the Programmable Operator. 


DASD BLOCK I/O 


To connect to the DASD Block I/0 system service, *BLOCKIO should be specified as 
the userid in the IUCV connect parameter list. This system service provides 
device independent access to CMS disks formatted with a blocksize of 512, 1K, 
2K, and 4K bytes. It provides the user with the ability to asynchronously read 
or write a full block of data to a CMS disk. This system service uses the new 
"parameter list data" protocol. This system service was introduced in VM/SP 
Release 3 and is used by SQL/DS. 
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CMS IUCV SUPPORT 


WHY IS CMS IUCV SUPPORT NEEDED ? 


IUCV treats a virtual machine as a single communications entity. Because of 
this, only one external interrupt buffer can be declared to IUCV for saving 
interrupt information. Also, in CMS, only one exit is available for handling 
external interrupts. The exit is defined by the HNDEXT macro, and it exit is 
responsible for handling all external interrupts, not just IUCV interrupts. 


A problem occurs if two programs running in one virtual machine wish to use 
IUCV. Since only one external interrupt buffer and one general exit is permit- 
ted, both programs must coordinate their use of the buffer and the exit. This 
coordination is unlikely to occur when programs are developed in different parts 
of the world or if the developers never expected the two programs to be used 
together. 


CMSIUCV SUPPORT 


The CMS IUCV support introduced in VM/SP Release 3 solves these problems. With 
this support, CMS manages the external interrupt buffer and allows programs to 
define exits which will receive control only when an interrupt is intended for 
their program. One exit is permitted for each IUCV path, and an exit can also be 
defined to handle pending connect external interrupts which occur before a path 
is defined. The CMS external interrupt handler, DMSITE, has been modified to 
route JUCV external interrupts to the user defined exit addresses. 


Two new functions are provided in the CMS IUCV support which allow programs to 
set up IUCV external interrupt addresses: 


° HNDIUCV 


. CMSIUCV 


HNDIUCV function 


The HNDIUCV function is a program identification function. It must be issued 
before any IUCV functions are performed to identify the program as an IUCV pro- 
gram. An exit address can be specified which will receive control whenever a 
pending connect external interrupt occurs for that program. A user fullword is 
available which is a fullword of storage that can be used to pass information to 
the exit routine. When the exit routine is driven, this fullword is passed to 
the exit in a register. A macro is provided in standard, list, and execute for- 
mat to aid users in coding this function. 
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CMSIUCV function 


The CMSIUCV function is a communication initiation and termination function. It 
should be issued whenever a program would normally have issued an IUCV Connect, 
Accept, or Sever. All other IUCV functions will be issued directly by a 
program. The CMSIUCV function issues the requested IUCV function, Connect, 
Accept, or Sever and then establishes a path specific exit which will receive 
control whenever an external interrupt occurs on the path. For the Sever func- 
tion, the exit is terminated. A user word is available with the CMSIUCV macro 
also, and the macro is provided in standard, list, and execute forms. 


CMS IUCV exits receive control as an extension of the CMS external interrupt 
handler. When driven, the significant registers contain: 


¢ RO  UWORD 

: Rl Savearea containing the registers and PSW 
: R2 External Interrupt Buffer 

. R13 User Savearea 

°e R14 Return address 


: R15 Entry address 


A COMPARISON OF IUCV AND CMS IUCV 


* HNDIUCV SET replaces IUCV Query and Declare Buffer 
¢ HNDIUCV CLR replaces IUCV Retrieve Buffer 
. CMSIUCV replaces IUCV Connect, Accept and Sever 


e "EXITS" replace the HNDEXT exit 


LIMITATIONS OF THE CMS IUCV SUPPORT 


Because IUCV treats the virtual machine as a single communications entity and 
CMS application programs run in supervisor state, there are some limitations of 
the CMS IUCV support. Programs using the CMS IUCV support are not entirely 
independent. Programs should not use IUCV functions which eliminate or bypass 
external interrupts. Since the external interrupt routing mechanism is the 
basis of the CMS IUCV support, if external interrupts are avoided, the CMS IUCV 
support will be useless. Also, many IUCV functions affect the entire virtual 
machine and if any of these functions are indeed issued by a program, other pro- 
grams running in the virtual machine may be affected. CMS can not prevent a 
program from issuing such an JUCV function, because an IUCV function is issued 
directly and can't be intercepted by CMS. 
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SUMMARY OF THE CMS IUCV SUPPORT 


With the addition of the CMS IUCV support, using IUCV from CMS is made easier. 
In particular, it allows multiple programs running in one virtual machine to use 
IUCV within certain guidelines. CMS manages the external interrupt buffer and 
routes external interrupts to user supplied exit addresses. In this manner, 
programs no longer have to handle all external interrupts, but just those IUCV 
interrupts which are intend for their programs. The CMS IUCV support does have 
it's minor limitations, however, the new support makes it much easier to use 
IUCV than what exists today, and it does provide multiple programs running in 
one virtual machine with the ability to use IUCV. | 
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FILE: MSG ASSEMBLE A 


233 BBB BERIT TIS I HAI IE 


This program demonstrates how one right use the new CMS IUCV 
support in VM/SP Release 3 to utilize the CP Message Systen 
Service. It establishes cornaunications via IUCV and then 
vaits for incoming messages. Each time a message comes ins 
it is logged in a file named 'MSG FILE’. When the user 
wishes to have the program terminate, he sends himself-a 
message which contains ‘STOP’. 


This progran does work (I've tried it), however, it could use 
a lot of work as it virtually ignores any error conditions. 
It is presented as a sanple and should be viewed as such. 


The program illustrates some of the new functions which vill 
be available in VM/SP Release 3. The function invocations» 
macro operands, parameter list formats, etc. are all subject 
to change vhen VM/SP Release 3 is nade available. 


KKK KK KKK KK KK KK KK KKK 
KKKK KKK KKK KKK KKK KKK 


$C 36 96 9 HEHE IEEE HEHEHE IEE HEHE IE IE IE EEE SEE IEDEIE IE EEE IE IEE EEE ESEIEEPENDEE DETTE TEESE TEE FETE HEHEHE IE 
SPACE 2 

MSG CSECT 
BALR R1i2,0 Establish 
USING *,12 addressability 
USING NUCON,RO 
SSM DISABLE Disable interrupts till we want en 
LR 11,14 Save the return address in R11 


Tell CMS that this program wishes to use IUCV, and will be 
identified by the name of SAM. An address is given for pending 
connects, hovever, this should never happen. 


eX KK K 


HNDIUCV SET,NAME=SAM, EXIT=CONPEND 
LA R2,IUCVPLST Get the address of our IUCV parameter 
USING IPARML,R2 list and establish addressability 


Build the parameter list with the IUCV macro,» then establish the 
connection and set up the path's exit 


x KK * 


IUCV CONNECT, PRMLIST=(R2) ,USERID=STARMSG »MF=L 

CMSIUCV CONNECT, NAME=SAM, PRMLIST=(R2) ,EXIT=MSGPATH 

MVC PATHID(2),IPPATHID Save the path id IUCV gives us 
DROP R2 


Wait for *MSG to tell us our connection is complete. Our exit will 
post the CONCOMP ECB when the interrupt cores in. Note that WAITECB 
internally will enable us for interrupts. 


K KKK *K 


WAITECB ECB=CONCOMP , FORMAT=0S 

LA R1,SETMSG Issue the SET MSG IUCV command to 
svc 202 Tell CP we want rnessages via IUCV 
pc AL4(1) 


% Wait here for ranessages. The MSGIN ECB will be posted each time a 
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MSG00010 
MSG00020 
MSG00030 
MSG00040 
MSG00050 
MSG00060 
MSG00070 
MSG00080 
MSG00090 
MSG00100 
MSGO00110 
MSG00120 
MSG00130 
MSG00140 
MSG00150 
MSG00160 
MSG00170 
NSG00180 
MSG00190 
MSG00200 
MSGO0210 
MSG00220 
MSG00230 
MSG600240 
MSG00250 
MSG00260 
MSG00270 
MSG00280 
MSG00290 
MSG00300 
MSG00310 
MSG00320 
MSG00330 
MSG00340 
MSG600350 
MSG00360 
MSG00370 
MSG00380 
NSG00390 
NSG00400 
MSG00410 
MSG00420 
MSG00430 
MSG00440 
MSG600450 
MSG00460 
MSG00470 
MSG00480 
NSG00490 
MSG00500 
NSG00510 
MSG00520 
MSG00530 
MSG00540 
MSG00550 


FILE: MSG ASSEMBLE A 


¥ 
* 


* 
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message comes in. If the message is 'STOP', quit and cleanup, 


WAITLOOP EQU : * 


* 
% 
* 
* 
* 
c 


otherwise, write the msg to a log file name 'MSG FILE' 
WAITECB ECB=MSGIN, FORMAT=0S 
CLC HSGAREA+8(4),=CL4'STOP' If the message says to stop, 
BE CLEANUP Stop and cleanup 


FSWRITE 'MSG FILE A’,FORM=E,BUFFER=MSGAREA,RECFM=F ,BSIZE=140 
xc MSGIN(4),MSGIN Zero out the ECB 
B WAITLOOP Wait for next rnessage 


Issue the CP SET MSG ON command to tell CP we no longer want 
messages via IUCV. Then issue the HNDIUCV CLR nacro to tell CMS 


LEANUP EQU x 


we no longer wish to use IUCV and return to CMS. 
LA R1,SETON Issue the SET MSG ON command to 
Svc 202 Tell CP we no longer want our 
DC AL4(1) messages via IUCV 
HNDIUCV CLR»NAME=SAM 
BR Ril return to CMS 
DROP Ri2 
EJECT 


HEHEHE HEHE HE IE IE IE HE IE IE HEE IE HE FE HE IESE HE FE HEHE FETE HE IE HE IE HE SE IE HE IE FE IE DE HE HE FE IE DE IE IE HEME DE IE IE HE IEE IE IEE IE HE IE HE IE FE IE HEHE IE IEE 
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MSGPATH 


This is our external interrupt exit for the path we've set up 
between *MSG and ourself. It works as follous: 


Connection Complete : Post the CONCOMP ECB and return 


Incoming message : Receive the message data into our rnessage 


KKK KKK KK K 


buffer, post the MSGIN ECB and return. 
JB BOER RIBEIRO BEEBE HE BB BRB BEBE BHEBEE 
SPACE 2 
EQU ® 
BALR R12,0 Establish 
USING *,R1l2 addressability 


or MSGIN;X'40' 
BR R14 and return to CMS 


USING IPARML,R2 R2 points to ext. int. buffer 

CLI. IPTYPE,X'02' Is it a connection complete ?? 

BE CONNCOMP If so, it's a special case 

xc IUCVPLST(40)},IUCVPLST Zero out the IUCV parameter list 
XC MSGAREA(140),MSGAREA and the nessage buffer 

MVC = MSGCLASS,IPTRGECLS Save the class 

MVC MSGID,IPNSGID and the id of the nessage 

LA R2,IUCVPLST Let R2: point to the PRMLIST 


Get the message which has been sent to you by issuing an 
IUCV RECEIVE. Put the message in MSGAREA. 


SYSTEM 


MSG00560 
MSG00570 
MSG00580 
MSG00590 
MSG00600 
MSG00610 
MSG00620 
MSG00630 
MSG00640 
MSG00650 
MSG00660 
MSG00670 
MSG00680 
MSG00690 
MSG00700 
MSG00710 
MSG00720 
MSG00730 
MSG00740 
MSG00750 
MSG600760 
MSG00770 
MSG00780 
MS600790 
MSGO00800 
MSG00810 
MSG00820 
MSG00830 
MSG00840 
MSG00850 
MSG00860 
MSG00870 
NSG00880 
MSG00890 
MSG00900 
MSG00910 
MSG00920 
MSG00930 
MSGC00940 
MSG00950 
MSG600960 
MSG00970 
MSG00980 
MSG00990 
MSG01000 
MSG01010 
MSG01020 
MSG01030 
MSG01040 
MSG01050 


IUCV RECEIVE, PATHID=PATHID; PRMLIST=(R2 ) ,MSGID=MSGID » TRECLS=MS*MSGO01060 


GCLASS ,BUFFER=MSGAREA, BUF LEN=BUFERLEN 


Post the MSGIN ECB 


MSG01070 
MSG01080 
MSG01090 
MSG01100 


08¢ 


FILE: MSG 


*% 


ASSEMBLE A 


4 
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* Come here if it's a connection complete interrupt (IPTYPE = X'02'} 


¥% ; 
CONNCOMP 


% 


EQU  ¥ 
or CONCOMP»X'40' 
BR R14 


Post the CONCOMP ECB 
AND RETURN 


* This is our connect pending exit. It should never be driven. 
* If it is, ve'll just ignore it and return. 


7 i 
CONPEND 


EQU) 
BR R14 
EJECT 


RBBB HBO HRB ERB RBBB BBB BRB BABE BBB BERR 


* 
* 
* 


EQUATES andCONSTANTS 


* 
* 
% 


FE IE HE IEE SESE IE IE SE IE IE FE BE BE BE DEDEDE HE IEE IE IESE SE IE FE JE DE SE EIEIE IEE IE 90 JE 98 38 9 9096 96 9 IE EEE 8 98 28 IE 96 9 IE SEES IE IEE IE IEEE 


SETHSG 


SPACE 2 

DS 0D 

oC CL8'CP' 
bc CL8'SET’ 
oc CL8'MSG' 
oc CL8'IuCcV' 


‘DC 8X" FF! 


SETON 


oc CL8'CP' 
DC CL8'SET' 


‘oc CL8'MSG' 


IUCVPLST 
MSGID 
MSGCLASS 
STARMSG 
SAM 
CONCOMP 
MSGIN 
PATHID 
BUFERLEN 
NSGAREA 
DISABLE 


oc CL8'ON' 
boc BX'FF? 

DC “G0X'00' 
dS F 

DS F 


DC CL8'*MSG6' 
DC CL8'SAM' 


bc F'o' 
DC F'o' 
oc H-0' 
DC H'140° 
DC CL140' 
oc X'00' 
REGEQU 
NUCON 

COPY IPARML 
END 


Parameter list to tell CP ue 
want our message via IUCV 


Parameter list to tell CP we 
want our message set back 
to 'ON'. 


Used for the IUCV parameter list 
Holds the IUCV message id 

Holds the IUCV message class 

The name of the IUCV Message Service 
Name vhich CMS will know us by 
Connection Complete ECB 

Message has arrived ECB 

Holds the IUCV path id 

Says our buffer vill be 140 chars 
Message buffer area 

Byte to disable us for interrupts 


MSG01110 
MS601120 
MSG01130 
MSGO01140 
MSG01150 
MSG01160 
MSG01170 
MSG01180 
MSG01190 
MSG01200 
MSG01210 
MSG01220 
MSG01230 
MSG01240 
MSG01250 
MSG01260 
MSG01270 
MSG01280 
MSG01290 
MSGO01300 
MSG01310 
MSG01320 


MSG01330 - 


MSG01340 
MSGO01350 
MSG01360 
MSG01370 
MSG01380 
MS601390 
MSG01400 
MSG01410 
MSG01420 
MSG601430 
NSG01440 
MSG01450 
MSGO01460 
4SG01470 
MSG01480 
MSG01490 
MSG01500 
MSG01510 
HSG01520 
NSG01530 
MSG01540 
NSG01550 
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